Secure Sockets Layer (SSL) and Transport Layer Security (TLS), which is the successor to SSL, provide secure network connections. SSL and/or TLS are commonly used during web browsing (e.g., using HTTPS), email, and other Internet applications. SSL and TLS are described in several Request For Comments (RFCs), including RFC 2246 (describing TLS 1.0), RFC 4346 (describing TLS 1.1), RFC 5246 (describing TLS 1.2), and RFC 6101 (describing SSL 3.0).
An SSL or TLS client and server negotiate a set of parameters to establish a secure session in a process called a handshake. For example, the client transmits a hello message (referred to as a ClientHello message) that includes the following: an indication of the requested version of the SSL or TLS protocol, a requested session identifier used to identify the session connection, a list of the cipher suites (cryptographic options) supported by the client, a list of the compression methods supported by the client, random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports.
In response, the server transmits a hello message to the client (referred to as a ServerHello message) that includes the version of the SSL or TLS protocol supported by the server, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the ClientHello message), the selected compression method (selected from the list of compression methods included in the ClientHello message), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may include a list of the extensions that the server supports.
Following the hello messages, the server transmits a list of its certificate(s) in a message referred to as a Certificate message (sometimes referred to as a Server Certificate message). The server then transmits a message indicating that the hello-message phase of the handshake is complete (referred to as a ServerHelloDone message). For some implementations, depending on which key exchange methods are used (e.g., implementations using Diffie-Hellman cipher suites), the server also transmits a message to the client (referred to as a ServerKeyExchange message) that conveys cryptographic information to allow the client to calculate the premaster secret. This message is signed using the private key of the server. The client then transmits a message to the server (referred to as a ClientKeyExchange message) that includes a random value typically generated by the client called a premaster secret or Diffie-Hellman parameters that allows the client and server to agree upon the same premaster secret. The premaster secret is used by both the client and the server to generate a shared secret (referred to as the master secret) that is used to generate session keys that are used to encrypt and decrypt information during the secure session. If the premaster secret is included in the ClientKeyExchange message, it is encrypted using the public key in the certificate sent by the server. By way of a specific example, if the Rivest-Shamir-Adelman (RSA) algorithm is being used for key agreement and authentication, the client generates a 48-byte value for the premaster secret and encrypts it using the public key from the server's certificate and transmits the encrypted premaster secret to the server. By way of another specific example, if a Diffie-Hellman implementation is used, the ClientKeyExchange message includes the client's Diffie-Hellman public value. By way of another specific example, if a FORTEZZA hardware encryption system is being used, the client derives a token encryption key (TEK) using the FORTEZZA Key Exchange Algorithm (KEA), which itself uses the public key from the server's certificate along with private parameters of the client, generates a random 48-byte value for the premaster secret and encrypts it using the TEK and transmits the encrypted premaster secret to the server.
If the server receives the encrypted premaster secret in the ClientKeyExchange message, it decrypts it with their private key. In an implementation where the ClientKeyExchange message includes cryptographic parameters to generate the premaster secret, the server generates the premaster secret using those cryptographic parameters (which also requires the use of the private key).
The client and server each perform a series of steps to generate a master secret from the premaster secret, using the random data included in the ClientHello and ServerHello messages (e.g., the ClientHello.random and ServerHello.random). The master secret is a shared secret that is used to generate session keys, which are symmetric keys that are used to encrypt and decrypt information during the secure session.
The client then transmits a message to the server informing it that future messages will be encrypted (referred to as a ChangeCipherSpec message). The client then transmits an encrypted message to the server for validation (referred to as a Finished message). The server transmits to the client a message that future messages will be encrypted (a ChangeCipherSpec message) and an encrypted message to the client for validation (a Finished message). From then on, the handshake is complete and the secure session is established such that future messages between the client and server are encrypted.